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Naming Rights in IETF Protocols 
Status of This Memo 


This memo provides information for the Internet community. It does 
not specify an Internet standard of any kind. Distribution of this 
memo is unlimited. 


Abstract 


This document proposes a new revenue source for the IETF to support 
standardization activities: protocol field naming rights, i.e., the 
association of commercial brands with protocol fields. This memo 
describes a process for assignment of rights and explores some of the 
issues associated with the process. Individuals or organizations 
that wish to purchase naming rights for one or more protocol fields 
are expected to follow this process. 


1. Introduction 


Normal engineering practice involves assigning names to fields in 
network protocols. These names are generally carefully chosen to 
reflect the function of the field, for example, the IPv4 Destination 
Address field. 


As protocol designers engage in their work, many become intensely 
involved with these protocol fields. Some of the most intense 
discussions within the IETF have been over details about such fields. 
In fact, it is an advantage to the continued viability of the IETF 
that dueling is outlawed in the countries in which it meets. 


But the financial realities of funding the Internet engineering and 
standardization processes may dictate that the IETF must consider 
whether names associated with such protocol fields represent an asset 
capable of responsible monetization. This notion may be offensive to 
some protocol purists; however, we believe the exigencies of the 
situation make the proposal below worthy of consideration. 
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This document describes a process and some issues associated with 
managing the sale of commercial branding rights (or naming rights) 
for IETF protocol fields. The authors believe that this modest 
proposal may serve as a source of revenue capable of supporting IETF 
standardization activities for years to come. 


This proposal arose from the realization that the sports industry has 
made energetic and successful use of naming rights, for stadiums in 
particular, e.g., the Staples Center in Los Angeles (basketball), 
Qualcomm Stadium in San Diego (football), Minute Maid Park in Houston 
(baseball), and the Aaron’s "Lucky Dog" get-a-lap-back (car racing). 


The Internet has enabled a new online economy that, even in the wake 
of the burst bubble in early 2000, is generating astounding growth 
and new services. It is clear that many old-economy companies would 
place high value on being associated with the new online economy and 
would be willing to pay for the privilege. Internet protocols are 
used around the world in myriad operating systems and devices. To be 
part of the Internet protocols is to be part of the engine that is 
revolutionizing how commerce is done. Many protocol fields are 
displayed in popular user applications either as key aspects of the 
GUI or in error or diagnostic messages. By requiring the use of the 
branded protocol field, the IETF is in a position to put client 
company brands in front of not only the thousands of software 
developers who build with these protocols but also the hundreds of 
millions of users who benefit from them. Finally, those who license 
and brand a protocol field will be able to use that field in their 
other marketing and claim, truthfully, that they are "in the 
network". 


This proposal includes creating a primary name value for each 
protocol field in the IANA registry and setting up a process whereby 
an organization or an individual can license the right to record a 
name of their choice in that field. 


This document makes the case for the need for additional revenue for 
the IETF (Section 2), followed by an introduction of the concept of 


branding in IETF protocols (Section 3). Several rules and 
constraints necessary to make such a revenue stream practical are 
then explored (Sections 4-14). Finally, this memo concludes with an 


initial assessment of the changes required by the IANA and RFC Editor 
to support such a service (Sections 15-17). 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 


"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 
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2's 


3: 


Revenue Needs 


Running the IETF is not inexpensive. It was reported at the 71st 
IETF meeting in Philadelphia, PA, USA that the 2008 budget [BUDGET] 
for the IETF had surpassed US$4.5 M, up from $4.1 M in 2007. About 
USS3 M of revenue in this budget flows directly from IETF activities, 
including meeting fees and sponsorships, and the remainder flows from 
the Internet Society (ISOC). Over the last few years the IETF has 
had to raise meeting fees repeatedly in order to keep this budget 
balance reasonable. 


Raising an additional US$1 M from the rental of naming rights could 
significantly change the budget dynamics. Perhaps meeting fees could 
be reduced for all attendees or special subsidies could be provided 
to needy students, researchers, or job seekers. Other options for 
the use of the increased revenue could be sizing the break cookies 
large enough to feed a family of geeks for a week rather than the 
mere day and a half as was the case at the 71st IETF, or renting out 
a bar for the working group chairs social rather than having to put 
up with the rowdy locals. There are many other equally deserving 
ways that the IETF could spend the resources generated by this 
proposal. It should be noted that any such benefits may have to be 
delayed for a few years to pay for the startup costs noted below. 


How Are Branded Protocol Fields Used? 


.1. Within the IETF 


When a protocol field name is licensed from the IETF, all future IETF 
activities, and documentation for products claiming to conform to 
IETF standards, MUST use the complete branded name. The output from 
protocol implementations, and associated documentation, MUST be 
considered non-conformant if the complete branded name is not used. 


-2. Externally 


The official IETF name for a purchased field is the complete branded 
name. Thus, all externally generated documentation that references 
the protocol must be considered incomplete unless it used the 
complete branded name where one exists. The IETF leaves it to the 
licensee to enforce the use of complete branded names in non-IETF 
documents. 
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4. Names Must Be in Good Taste 


The combination of brand names and protocol field names must avoid 
uses that may be considered offensive by some part of the Internet 
community. Name purchases shall be reviewed for taste. Prospective 
purchasers must prepare a proposal for how the branded protocol name 
will be used in advertising or other media. (Note that a well- 
developed taste-review process may prove useful for other IETF 
activities, for example, IETF working group names, T-shirts, and host 
presentations.) 


Within the limits of taste, the branded protocol field may be used 
for any purpose. 


5. When Names Change 


As has been discovered in other areas where naming rights are sold or 
leased, commercial realities and developments mean that a brand name 
can suddenly go out of favor or even cease to denote an existing 
entity. In addition, branding is leased (i.e., sold to be used over 
a limited time) and the branding for a particular field may change 
when the lease is up. Thus, there must be a mechanism to change 
branding when needed. See the IANA Considerations, RFC Editor 
Considerations, and Tools Considerations sections for more 
information. 


6. Example Names 


The most effective names are those that pair the semantics of a field 
with a characteristic desirable to a sponsor. The following examples 
of good and bad pairings illustrate how an appropriate pairing can be 
appealing. 


6.1. Acceptable Taste-Wise 


IP: Garmin GPS Destination Address 

IP: White & Day Mortuary Time-to-live 
TCP: Princess Cruise Lines Port Number 
ARP: Springfield Preschool Timeout 

BGP: Sharpie Marker field 

TFRC: Traveler’s Insurance Loss Period 
SCTP: Hershey’s Chunk {type|flags|length} 
SMTP: eHarmony HELO 
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Protocol names appear within the fields of other protocols; 
therefore, the protocols themselves may be candidates for branding: 


BEEP: AAA BEEP 
SOAP: Downey SOAP 
PPP: FloMax PPP 


There is no requirement for branding to be limited to company names 
or other trademarked terms. For example, a publisher could decide to 
honor one of their authors: 


The Thomas Wolfe Source Address Field 
6.2. In Bad Taste 


SIP: Seagrams Vodka SIP Event 
SIP: Calvin Klein Event Package 
IP: Viagra Total Length 


6.3. Confusing Names 


Places where the brand could interfere with the understanding of the 
protocol are prohibited: 


SMTP: US Postal Service Mail command 
IPv6: ITU-T Protocol field 
IKE: RSA Vendor ID 


6.4. Valid Names 


In order to be printed in the ASCII-only Real-RFC (described in 
Section 16) all brands must include an ASCII form. The ASCII name 
MUST conform to the requirements in RFC 2223 [RFC2233]. The brand 
MAY optionally include a UTF-8 version for use in non-ASCII 
representations. See RFC 3629 [RFC3629]. 


7. Who Can Buy Naming Rights? 


Any organization or individual can purchase the right to brand a 
protocol field. The IETF will not undertake to ensure that the 
purchasing organization has the right to use the name they choose to 
use. All purchasing organizations MUST indemnify the IETF against 
any challenges to the authority of the purchasing organization to use 
the name. 
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8. Scope of Naming Applicability 


Because the application of IETF protocols is not controlled in a way 
that corresponds to legal jurisdictions, it is difficult to restrict 
naming rights to include just those places where a particular 
trademark may be registered. The process described in this memo does 
not include the use of geographic or geopolitical boundaries on the 
use of branded fields. The design team is working on a proposal to 
overcome this issue. If the design team is successful, the same 
proposal should find application in a number of areas of 
international diplomacy. 


9. Who Can Sell Naming Rights? 


The IETF SHALL retain the sole right to permit branded protocol names 
to be used within IETF protocols. The IETF MAY sell rights for 
external use of branded protocol names if the protocols have been 
developed within the IETF process and if the protocol field has not 
already been branded by someone else using the same process. 


10. Pricing 


Multiple pricing strategies for the naming rights to protocol fields 
will likely be used over time. The primary objective of pricing is 
to enable the greatest possible revenue for the IETF. Initially, 
prices will be set by negotiation between the party wishing to 
purchase the naming right and the Internet Auction Board (IAB) 
representative. However, we strongly suggest migrating to an all pay 
auction (also known as a Tullock auction) for finding the optimal 
price when there are multiple bidders [KOVENOCK]. Alternatively, 
open-outcry auctions [EKLOR], perhaps with a secret reserve price, 
could be held at IETF meetings using a BoF session, permitting taste 
review and brand assignment (sale) to be conducted concurrently and 
with open participation. See [MILGROM] for information on various 
auction styles. 


11. Time of Ownership 


The design team could not come to consensus on a default term of a 
lease of the authority to name a protocol field. It was split 
between a term that would best represent the half-life of an Internet 
startup (1 or 2 years) and a term that would best represent the 
half-life of a product offered by a mature Internet company (8 to 10 
years). The idea of terms any longer than 10 years, for example, 
leases that would terminate when a protocol advanced on the standards 
track (i.e., roughly infinite), was discussed but generally discarded 
because so few companies survive in any recognizable form for that 
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length of time in the Internet space. In the end, the design team 
concluded that the lease term should be part of the negotiation 
between the IETF and the purchasing organization. 


12. How Are Naming Rights Purchased? 


The right to name a protocol field is purchased using the following 
process: licensees complete an application where they identify the 
protocol field they wish to use and the particular RFC in which it 
appears (Internet-Draft tags are available for short term lease). At 
that time, they identify their brand and present their proposal for 
external use and length of ownership. The next step is a taste 
review followed by an auction or IAB negotiation. The purchase 
concludes with the IANA updating their protocol field name mapping 
database. 


13. Dispute Resolutions 


All disputes arising from this process MUST be resolved using the 
ICANN Uniform Domain-Name Dispute-Resolution Policy [UDRP]. While 
the protocol fields are not domain names, branding them presents the 
same types of issues and we feel that it’s better to make use of an 
existing process rather than to invent a new one. 


14. Future Expansions 


If this proposal proves successful, it can be easily expanded to 
include other protocol features such as options and parameters. For 
example: 


IPv6: The Herman Melville Jumbogram option 
15. IANA Considerations 


Upon the adoption of this proposal the IANA SHALL set up a protocol 
field-to-brand-name database (the "IETF Protocol Branding Catalog") 
that includes all protocol fields in IETF-developed or -maintained 
protocols. This database can be bootstrapped from the existing 
protocol registries database [PROTREG], but this list will have to be 
augmented to include all fields in all IETF protocols, even the ones 
in which no IANA assignments are made. 


The two brand name fields associated with each protocol field (the 
ASCII field and the optional UTF-8 field) are initialized as NULL. 
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Whenever the IETF leases a protocol field, the IANA SHALL enter the 
brand name(s) into the brand-named fields associated with the 
protocol field and SHALL set the lease termination date to the proper 
value. 


In addition, the IANA SHALL regularly scan the database to look for 
leases terminating within the next 30 days and inform the IETF of any 
such leases so that the IAB can approach the leaseholder to sign up 
for an additional term. The IANA SHALL remove any brand names from 
their database when the lease expires. 


16. RFC Editor Considerations 


Upon the adoption of this proposal the RFC Editor SHALL create XML 
versions of all IETF RFCs. The XML must be such that a perfect copy 
of the original RFC can be produced using a tool such as xml2rfc 
[XML2RFC]. The XML versions of RFCs must identify all individual 
protocol fields using an XML protocol field element of the form: 


<pfield name="IPv4 Destination Address"/> 
(Doing this for all existing RFCs may involve some work.) 


As the XML RFCs are completed, the RFC Editor SHALL then create an 
ASCII version of the RFC from the XML file using the naming 


convention of "Real_RFCxxxx.txt". During the translation, each 
protocol field is looked up in the IANA protocol field-to-brand name 
database. If there is an ASCII brand name associated with the 


protocol field, the word "the" and the brand name are prepended to 
the IETF name for the field (unless the name appears in ASCII art 
where changing the length of the name would distort the art). For 
example, if the protocol field is "Destination Address" and the brand 
name in the IANA database is "Garmin GPS", the string "the Garmin GPS 
Destination Address" would be used in the Real_RFC. Changing the 
lengths of such names may require adjusting the other details of the 
document such as page numbering in the Table of Contents. The 
software to do some of the formatting might be a bit tricky. 


The RFC Editor may optionally produce other non-normative versions of 
Real_RFCs. For example, a non-normative Portable Document Format 
(PDF) version may be created in addition to the ASCII Real_RFC 
version. The RFC Editor may use the UTF-8 brand, if present, in such 
alternate versions. 


The Real_RFC SHALL be used for all normal purposes within the IETF 


and elsewhere with the original version being reserved as an archival 
reference. 


Falk & Bradner Informational [Page 8] 


RFC 5241 Naming Rights 1 April 2008 


The RFC Editor SHALL rebuild all the Real_RFCs on a regular basis to 
create up-to-date Real_RFCs that reflect the current status of the 
protocol field licenses. 


The RFC Editor SHALL provide a list of un-leased field names to the 
IANA for inclusion in the IETF Protocol Branding Catalog. 


17. Tool Builder Considerations 


Upon the adoption of this proposal, the maintainer of the official 
xml2rfc tool SHALL update the tool to support the protocol field 
element and to consult the IANA database when being used to produce 
Real_RFCs (or Real_IDs). Upon the adoption of this proposal, 
document authors will be required to transmit the raw XML input file 
for the xml2rfc tool to the RFC Editor when the document is approved 
for publication. 


18. Security Considerations 


The fact that the IETF will not undertake to ensure that the 
purchasing organization has the right to use the name they choose to 
use can lead to mischief. For example, a Microsoft competitor could 
purchase the right to name the IPv4 Header Security Flag [RFC3514] 
"the Microsoft Evil bit". 


19. Conclusion 


The discussion above has introduced the concept of branding IETF 
protocols and the associated implications. Clearly there are non- 
trivial costs to starting up and maintaining such a revenue stream. 
However, advertising has a long and distinguished history of 
supporting valuable community services such as free broadcast 
television and Google. 


As branded protocols become established, new protocols will be 
developed with names conducive to branding. In fact, licensees may 
initiate new IETF work just to see an appropriate field established. 
So, besides the economic benefits to the IETF, this initiative may in 
fact help ensure the IETF is never without work and, thus, self- 
sustaining and self-perpetuating. 
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